\chapter{Conclusion}
\label{Conclusion}

The main goal of this work was to improve software quality attributes using a
real software as study case, comparing performance metrics during this refactoring process.
Such approach is relatively original, and our preliminar results show it is a
really useful and promising research issue.

AppMan was chosen for several reasons. First, this work is part of the GRAND 
project and thus improving AppMan quality is strongly desired. In spite of being
a research project, it was developed by a distributed team, using tools and methods that
are currently used both in industry and academy. Finally, the code had
complexity enough as well design problems that justify a refactoring for improving maintainability.

The main contribution of this work is the fact that we could show that a good
programming practice does not necessarily implies bad performance. Although
only preliminary results are shown, our results are promising. For the
presented refactoring cycle, we could both improve software quality and
performance metrics. Table \ref{table:finalTable} presents the main results
concerning quality software improvements. After such improvements, we still get
speedup and efficiency as presented in previous chapter.


\begin{table} [hbtp]
\begin{center}
\caption{Appman - Comparing cohesion classes using LCOM-CK metric}
\label{table:finalTable}
\begin{scriptsize}
\begin{tabular}{c|c|c|c}
\hline
Original  & After Refactoring & Type & Package\tabularnewline
\hline
\hline
619 & 165	&  Task	& appman.task\tabularnewline
\hline
65 & 60	& SubmissionManager	& appman\tabularnewline
\hline
82 & 49	& ApplicationManager	& appman\tabularnewline
\hline
18 & 17	& TaskManager	& appman.task\tabularnewline
\hline
\end{tabular}
\end{scriptsize}
\end{center}
\end{table}



As future work, our AppMan version can be integrated with current version
implemented by \citet{bernardo:2007}. This ongoing new version uses a standard 
application programming interface called DRMAA to allow integrating AppMan with
different Resource Management Systems such as PBS. Integrating both versions will
provide a more mature and stable infrastructure for future works on GRAND Project.

New refactoring cycles can be implemented in the original version as well 
as in the integrated version. These new cycles can consider new quality
attributes like coupling or complexity. Cohesion can be analyzed again
considering other quality metrics and the classes cohesion in a group because
this work analyze only level zero (method) and level one (class). This can
improve much more this object-orientation key concept.

Finally, new software quality metrics should be used, trying to get more
suitable metrics to OO context. As \cite{gupta:1997} critique, the cohesion
metrics were not suitable to this kind of application because of some
limitations in its calculations which required some more effort to make this
work happen. GQM (Goal, Quality, Metrics) can be used to evaluate the
software quality metrics used in this work. GQM is an approach to software
metrics which can be used to choose the right metrics and to drive the results
for decision making.

As presented initial chapters, there are several metrics and methodologies that
can be explored to get a better software quality. Checking how these new
refactoring cycles affect performance metrics will provide even more conclusive data.